本文同步發布於個人部落格

對於前端工程師而言，日常除了開發之外，處理各式各樣的 bug 也是重要業務一部分。
bug 這種東西齁，能說是儘管大家已經儘量避免，就算過了兩層 review 但就還是有機會發生。

最近滑 IG，看到一則我覺得滿好笑又挺中肯的：

Debugging / verb / Being The Detective In A Crime Movie Where You Are Also The Murderer.

看到只能說笑死 XD

預防錯誤

對於開發者來說，我們當然希望儘量不要出現 bug，因為 debug 很麻煩。
所以團隊在開發上通常就都會導入一些機制來減少 bug 的出現率，這些手段包括：

1. 統一的開發環境 - docker 和共用 DB
2. 統一的 coding style - 避開一些因為協作產生的坑，而且也提高易讀與維護性
3. 善用工具 - 包括 TS、ESLint、OpenAPI... 等
4. Code Review - 我們公司甚至過到兩層才會放行合併 MR
5. 寫測試 - 盡量 lib/composable 都寫測試，及早發現問題

儘管如此，bug 其實還是默默地潛伏在各個角落，這不管哪個公司還是團隊都是這樣。
看看微軟，每次更新可能都會有一些莫名其妙的 bug。
Next 在今年初甚至還爆發超大的安全性漏洞，拜託，Next 誒，一個那麼多人在用的 React 框架，因為一個滿微妙的 bug 產生了安全性漏洞。
所以看看，即使再嚴謹、再權威、再龐大的公司或團隊，總有百密而一疏的時候，bug 就這樣誕生。

其實 bug 會誕生真的是無可厚非。
公司再龐大其實 QA 也是有限。
我們都會笑說客戶其實是最好的 QA，這其實是半開玩笑半無奈啦。
很多時候都很想鍵盤砸下去問他：所以你幹嘛要這樣操作？
但其實 bug 產生的原因真的很多，包括：

1. 使用者的環境配置 - 就遇過使用者還在拿 ios 不知道幾的老古董，他家的 safari 跑不動我們的系統
2. 使用者的操作習慣 - 永遠無法預測使用者到底會怎麼操作
3. 程式執行緒出了問題 - 這偶發，但不是不可能

之類芸芸，族繁不及備載。

所以我們必須調查兇手

前端 debug 有幾大步驟，我願稱之為通靈步驟 XD
通常 PM 回報錯誤都會提供錯誤發生的頁面、引發錯誤的操作步驟，好一點的還會給 HAR 檔，可以方便查查 api error。
拿到這些資訊通常會需要做幾件事：

1. 看一下發生錯誤的版本是誰，拉一版下來本地執行，確保環境一樣
2. 照著 PM 提供的操作步驟重現問題
3. 看看問題發生的 element 會是 code 裡的哪個組件、哪個 function... 等

大概這樣三個步驟。
但其實最難的就是複現錯誤，因為有時候錯誤可能是偶發的。
或是即使用了一樣的版本，但 dev 跟 prod 始終還是有一些差異。
通靈技能往往是在這時點滿的。

如果對專案熟悉度夠高的話，能複現錯誤其實就大概能再把錯誤發生的原因範圍給縮小了。
因為現代開發通常都會把各項內容拆分成 component，夠熟悉專案就比較有辦法快速知道錯誤可能發生在哪個 component。
然後再去看這個 component 的 code，看看有沒有什麼不對的地方。

這裡也沒有要教什麼高深的 debug 辦法，什麼斷點啦那些，雖然也很有用，但我覺得最基本 debug 只要記住兩個好朋友就可以陪你一輩子：

1. devtool
2. console.log

或許會說：蛤？這不是最基本的嗎？面是不是都說只會 console.log debug 會被噹嗎？
但它真的很好用啊！
你要看某段 if block 有沒有進入執行 → 塞個 console.log 在 if 裡面；想知道資料變化前、變化後長相 → 塞個 console.log 在前後。
一目了然不是？

然後 devtool 也是超重要的工具。
不談那些大家都知道主控台、DOM 結構、CSS 結構。
React、Vue 都提供了 devtool extension，能讓你更方便地檢視 component 的 state、props、hooks... 等。
這對 debug 是大有幫助的！

但我覺得 devtool 真正 debug 強大是 api error 基本只能透過 devtool 來 debug，除非你家團隊有特別的 error handling，比如導入 Sentry。
devtool 的 network 可以看清楚所有 api request，甚至你可以自己 throttle 網路速度來模擬使用者的網路環境，這無疑是 debug 利器。
突然想到，這裡想提一嘴的是，devtool 對 GQL debug 較為辛苦一點，因為 GQL 不管成功失敗通通都是回應 200，你得一筆一筆點進去看。但好在，GQL 其實也有自己的 devtool extension，能讓你更方便地檢視 GQL 的 query、mutation... 等。

好啦，綜上所述，只是在闡述 debug 也是我們日常的一大部分。
發生原因千奇百怪，遇到了也只能面對它。
或是哪天能檢討客戶，記得叫我 XD